首先介紹這兩個名詞，在中文常都被翻譯成「編排」，但實際內涵不同：
當談到 Workflow Orchestration 通常也是指由 Workflow Engine 來進行編排，下列流程引擎所需能力。
為了避免誤用踩到陷阱，以下列出與排程及事件驅動的適用情境做為比較。
| 流程引擎 (Workflow Engine) | 排程 (Scheduler) |
|---|---|
| ✅ 適用情境 | ✅ 適用情境 |
| 長流程 / 跨天流程 | 固定時間批次（每日報表、ETL） |
| 狀態保存、可暫停與 callback | 簡單、獨立、無狀態任務 |
| 錯誤處理（重試 + 補償） | 高頻定時檢查（queue、快照） |
| 人工審核 / SLA | 維運自動化（備份、rotate log） |
| 複雜分支與條件路由 | |
| 完整審計追蹤（金融 / 醫療） | |
| 流程版本化 | |
| ⚠️ 常見誤用 | ⚠️ 常見誤用 |
| 固定批次任務（ETL、報表） | 長流程用輪詢模擬，流程易斷 |
| 單步任務（清理檔案、健康檢查） | 補償交易靠重跑，導致重複扣款 |
| 高頻輪詢（每 5 秒查 queue） | 人工審核靠排程查狀態，無 SLA |
| 等外部 callback 用輪詢 API → 成本高 | |
| 稽核只留日誌，無法還原全流程 |
| 流程引擎 (Workflow Engine) | 事件驅動 (EDA) |
|---|---|
| ✅ 適用情境 | ✅ 適用情境 |
| 長生命周期流程（貸款、理賠、物流跨境） | 單純廣播通知（新商品上架 → 搜尋、推播、寄信） |
| 狀態保存，可暫停與恢復（等待支付回呼） | 高頻、低延遲的即時事件（IoT 感測器、股價推送） |
| 錯誤處理與補償交易（Saga Pattern） | 去中心化消費（註冊事件 → CRM、Email、推薦系統各自處理） |
| 人工任務 / 審核 / SLA 管控 | 高併發、低價值事件（點擊、瀏覽紀錄） |
| 複雜分支與條件路由 | 資料流處理 / ETL 管線（Log → Kafka → Flink → ES） |
| 稽核、合規追蹤（金融、醫療） | |
| 需序列化與業務鎖（同一筆訂單需順序處理） | |
| ⚠️ 常見誤用 | ⚠️ 常見誤用 |
| 固定廣播也建成流程 → 成單點瓶頸 | 長流程用事件鏈串起 → 狀態分散、易丟失 |
| 高頻事件都開 workflow instance → 狀態暴增 | 需要補償交易卻沒設計回滾 → 不一致 |
| 點擊/瀏覽事件也保存狀態 → 資源浪費 | 人工審核靠「等事件」→ 缺 SLA/責任追蹤 |
| 等待外部 callback 自行維護 correlationId → 錯誤率高 | |
| 有稽核需求卻只靠零散事件 → 難以重建完整流程 |
| 流程引擎 (Workflow Engine) | AI Agent |
|---|---|
| ✅ 適用情境 | ✅ 適用情境 |
| 長流程、多步驟、需要確定性與可重放 | 探索性/開放式任務（資訊蒐集、規劃、生成） |
| 強狀態管理、SLA、審計/法遵 | 需要非確定性策略、工具使用與自主決策 |
| 跨服務交易、補償（Saga）、序列化處理 | 人機協作、自然語言介面、快速原型 |
| 視覺化、版本化、可回放測試 | 知識推理、模糊規則、內容生成 |
| ⚠️ 常見誤用 | ⚠️ 常見誤用 |
| 期待「智慧判斷」由流程引擎完成 | 讓 Agent 執行核心交易步驟（扣款/庫存） |
| 將不確定性決策放入確定性工作流 → 回放不一致 | 以記憶脈絡取代持久化狀態與版本管理 |
| 用引擎做資料擷取/生成 | 用 Agent 取代可靠重試/補償/審計 |
| 長流程靠自迴圈維持 → 崩潰即失狀態 |
📌 互補與整合建議
2015–2017 算是新一代引擎的起點，顯示這個需求在微服務與雲原生架構普及後被真正放大。
其實更早在 2000 年前後，BPM 陣營（jBPM、Activiti）就已經處理流程建模與系統/人員協調的問題，但主要針對企業簽核、系統整合，尚未可以處理 massive scale 的分散式挑戰。
新一代引擎則是把事件驅動、雲原生架構引入，引擎角色從「企業簽核工具」擴展為「分散式協調核心」。近期 AI 串接成為重點需求，這類引擎剛好能補上缺口，讓 AI 的運作更可靠，也更容易被觀測與治理。
因此，只要能正確識別需求，就能理解流程引擎雖不是萬靈丹，但在諸多場景（長流程、補償交易、狀態保存、跨服務協調）中是非常關鍵的解決方案。
下一篇將進一步介紹本系列主角 Temporal 的基礎架構。
iThome鐵人賽
看影片追技術